"Spatial analysis in the developing world: Measuring access with OpenStreetMaps and OpenTripPlanner" 
   By Phoebe Merritt.
   Live captioning by Norma Miller.
   @whitecoatcapxg
   
   >> Hi, everyone, let's welcome Phoebe. We're talking about spatial analysis in the developing world.
   >> Is this working? Good morning, I'm Phoebe, I'm a GIS analyst and developer at SpatialDev here in Seattle, and I'll be talking about using OpenStreetMaps data with OpenTripPlanner to create meaningful spatial analysis in developing parts of the world.
   So I wanted to start out by highlighting a use case that really spurred or interest in OpenTripPlanner in the first place. And that is, financial services, and their importance in places like Kenya, Uganda, and India. Researchers have found that one of the best ways to enable a person to transition out of poverty is to enable them -- is to ensure that they have access to a financial service and this allows for saving, borrowing, receiving payments, and other banking services that are essential to maintaining a business and personal savings. So to study the current status of financial access, we really need data like the locations of financial services, high resolution population data, and to really understand this.
   However, in areas like these, data is often reported at a very high country level, and spatial data is often pretty limited. Here, for example, you can see that the standard measure of financial access, this is from 2009, it's reporting the number of ATMs per 100,000 people for each country and this is very high level and almost a little bit of a crude measurement if you really want to understand financial service access on the ground.
   Not to mention, we are not working with any spatial data. However, recently there's been a large amount of financial data being collected thanks to organizations like the Bill and Melinda Gates Foundation, and the HOT OSM team, we now have some really great detailed precise financial data to work with.
   For example, the HOT OSM team just completed a pilot project. In Uganda. So we can see a large number of financial locations they collected and so just looking at southeast Uganda, we can see here that there's a lot of potential data to work with.
   And so we can use this data to create maps these, to give us a better standard measure of financial access. Here we're measuring the number ever people living within 5 kilometers of a financial service location, and this is done by generating a Euclidian distance buffer around each financial point, usually 5K, and then calculating the total population living within the union of these buffers, so this measure is a lot more spatially nuanced than the tabular data that we were looking at of ATMs per capita from 2009.
   However, although this is definitely an improvement, we wanted to get even more detailed than that. We wanted to know how long it takes someone to walk to a destination. So we basically wanted a smarter buffer, something that most closely aligns with the urban planning term walk shed. And we noticed that a lot of these points tend to be located along roads mapped in OpenStreetMaps. Which you can kind of see here in this screenshot of all of these purple financial points on top of an OSM base map and we actually measured the distance from each financial point to the closest OSM road and we saw that the majority of points are about 500 meters from a road, so knowing this, we really began to consider using OpenStreetMap road data to help us better understand financial access.
   So we started exploring OpenTripPlanner which is a transportation planning service created by routing experts who specialize in OSM data. So one of the best examples of OpenTripPlanner is this public transportation planner in Portland, which is completely powered by OTM or OpenTripPlanner.
   But what enticed us most about OpenTripPlanner was its analyst web services. This is what could help us create a better measure of financial access, so what we're looking at here are travel time isochromes or basically polygons of areas that can be accessed in the same amount of time. So in this part of Nairobi, it takes 20 minutes to get from the blue marker to the Reiter blue area, and 40 minutes to get to the darker purple. So I'm going to dive into the workload of how to create isochromes like this, basically outlined in these five steps. We're going to download, build a graph, configure our OTP instance, get our geo JSON polygon data and then pull it into QDIS to get some great analysis. So OpenTripPlanner has great information for basic usage and starting up an instance, but the main things to know is that it's written in java. It can run on pretty much any platform with a java machine. First thing we need to do is download this GR file which we can get from the documentation.
   So the next thing to do is to get an OpenStreetMap extract. Mapzen has some great extracts available to download. And so we're looking at cutting an extract of OpenStreetMap data, and it can range anywhere from a town to an entire country.
   So once we have our OSM extract we'll need to create an OpenTripPlanner graph which we can see here in this really cool visual that Brandon Henderson created. He's also created the OpenTripPlanner graph server. So this is basically a rendering of a growing shortest path tree on a street grid in Seattle. You can see I90 and the Burt Gilman are thicker branches. I believe this is bike trips.
   We're interpreting that data as a street grid made up of vertices and edges. So OpenTripPlanner's graph server will use these vertices and edges to route the most efficient trip from Point A to Point B.
   So before we can start up an OTP instance we have some configuration options. There's a JSON config file to dictate things like factoring in an elevation dataset and if we're using transit data, we can set limits on, for example, drive time to a park and ride, and a lot of other detailed options.
   I also want to mention that an OTP instance has several of what are called routers. These are specific independent regions like Portland or King County. And here in this file structure you can see they're using NYC and PDX. So each router has its own subdirectory and OpenTripPlanner can be used so all of these routers can be used in the same OpenTripPlanner instance.
   So with that in mind if we want to incorporate elevation data, we simply store a geo TIF in one of our router subdirectors and OpenTripPlanner will scan for this geo tif file. So in areas outside the US a good way to get that is to the tile grabber on the right which makes it very easy to download only the tiles of areas you need. Rather than using open dataset.
   And we've configured our open data, we can start making router requests, so this is what it looks like. Here's our web client with a nice map interface, and we've now spun up a working OpenTripPlanner instance.
   So we're now ready to start creating some travel time analysis, like these isochromes.
   The OTP analyst service used for different travel time analysis uses the same routing data that we he saw when we were making routing trips, so using OTP's API, we can generate travel time isochromes. Like starting coordinate, walk speed, cutoff sections which determine those colored polygons that we saw and our response from the server will be a geo JSON of these isochrome polycons. So here's a quick and dirty example of generating isochromes and dynamically rendering them on a leaflet map. So this is in Nairobi, Kenya, and we're using cutoff seconds of 10 minutes, 20 minutes, 30 minutes, all the way up to 50 minutes and using the geo JSON, we can also save it. So here we can begin to use theseisochromes, and I'll mention a couple different ways to use these isochrome polygons for GIS analysis, particularly with financial service data.
   So in this example, we can see here the stark difference between our regular buffer analysis in the light pink, and the smarter buffers or isochrons in red. So we can start to see that the number of people with access of an ATM in Uganda is very estimated when we're using the regular buffer analysis compared to isochrons. Our units are in minutes or hours rather than kilometers when we're working in isochron so that gives us a better example. Here rather than using one isochron like in the previous example we're using several. So we have 20 minute, 30 minute, and 60 minute isochrons for all the banks in Kenya and we're using it to find how much of the population is within walking distance, so using several isochrons like this allow us to see how distance varies with walk time. So in this example we can look at how complementary financial services relate to one another, so we're looking at Uttar Pradesh India. In the table we can see that financial services are broken down by type, like ATM, and commercial banks, within each walk time interval. So using this type of travel time analysis, we can look at not only where financial services are, but also how they relate to other services.
   So the advantages are definitely clear. We have, you know, creating smarter buffers, using OpenTripPlanner isochrons are detailed, they're as up to date as the OpenStreetMap extract, but the analysis is only as good as its underlying data. We're faced with some challenges when using this tool in areas that don't have a lot of map data in OSM.
   So for example, you can see here in rural Tanzania, there's not been a lot of OSM data mapped. OpenTripPlanner relies on its underlying road network to route trips and without a road network, you isochrons, but there are a few things we can do. One is to identify the max distance from a starting coordinate to an open road. The default is set to a thousand meters and if you were to increase this, that would mean that you could choose your starting coordinate, and if it was over 1,000 meters from the closest road, OpenTripPlanner would still be able to snap your starting coordinate to the nearest street edge and you'd still be able to create results.
   Another option is to just go ahead and map the missing roads in OpenStreetMap by tracing roads using satellite imagery. Here's an example on the left of a road in Tanzania that we digitized and added to OpenStreetMap in order to basically create a basic road network in the area we were working in. With this approach, however, we're missing a lot of OSM tags that you would see in urban areas on roads, like road speed, road surface, and several other factors that feed into OpenTripPlanner.
   But overall, we have the ability to get a much more granular, precise picture of financial access in the developing world by using OpenTripPlanner and OpenTripPlanner and so here are some great useful resources to that kind -- that kind of talk more about this topic, and thanks so much.
   [applause]
   All right, so if you have any questions, you can talk to Phoebe afterwards. We have to move on to the next speaker.